This invention relates in general to the field of computer architecture, and more specifically to a data release methodology for an on-chip system bus that reduces turn around latency on a data bus having multiple master devices.
A system bus in a computing system provides a communication channel between computing devices, such as microprocessors, graphics processors, direct-memory-access (DMA) controllers, and other devices such as memory, keyboard, monitor, video controllers, sound generation devices, etc. The system bus typically includes data paths for memory addresses, data, and control information. In some instances, a processor multiplexes (i.e., shares) address and data information over the same signal lines, albeit at different times. That is, a processor sends address information out over the address/data pins during a first time period and later uses the same address/data pins to send or receive data. Alternatively, many processors utilize separate signal lines for address and data information.
In operation, processors communicate with memory when they need to fetch instructions. During execution of instructions, processors might be required to read data from memory, or from another device such as an input/output (I/O) port. And, upon completion of instructions, processors might be required to write data to memory, or to another device. A typical scenario for accessing memory to obtain instructions and data is similar to the following:
1. A processor presents a memory address for an instruction on address lines of a system bus, and provides control information on control lines of the system bus to indicate that the operation is a read.
2. In response to the address and control information being placed on the system bus, memory places an instruction on data lines of the system bus, which are then read by the processor. The data is typically placed on the data lines N cycles after the address information has been placed on the address lines, where N is a positive integer and varies depending on the speed of the memory.
3. During execution of the instruction, if data is required, a memory address for the data is placed on the address lines of the system bus, and control information is placed on the control lines of the system bus to indicate a read.
4. Again, the memory places data corresponding to the memory address on the data lines of the system bus.
5. If the instruction needs to write to memory, the memory address for the write is placed on the address lines of the system bus, and control information is placed on the control lines to indicate a write.
6. N cycles after the memory address is presented, the data to be written is placed by the microprocessor on the data lines of the system bus. The memory uses the memory address presented in step 5, and places the data on the data lines into memory at that address.
One skilled in the art will appreciate from the above that the system bus provides the necessary physical interface between a processing device, and other devices (such as memory) that are external to it. A system bus is accompanied by a protocol necessary for communicating between devices. That is, the protocol defines when address, data, and control signals must appear on the system bus, in relation to each other. For example, in the illustration presented above, address information appears in parallel with control information. At some time later, data information is presented by the processor, or is provided by memory.
In environments where there is only one device capable of initiating bus activity (a uni-master environment), the above described sequence is generally sufficient. However, in environments where multiple processors compete for access to shared devices, arbitration is needed to assign time on the bus to the multiple processors.
For example, if there are two processors on a system bus, both competing for access to slave devices (such as memory), typical systems provide an arbitration protocol between the devices to establish which one has the right to begin. On the Pentium bus (designed by Intel Corporation), a processor requests access to the bus by asserting a xe2x80x9cbus requestxe2x80x9d signal. If the processor receives a xe2x80x9cgrantxe2x80x9d signal, either from another processor, or from an external arbitration device, then it begins a transaction by placing address and control information on the bus. When it receives (or writes) data on the bus, it relinquishes control of the bus to the next processor. If another processor required access to the bus during the transaction, it would have to wait until the entire transaction (including the address and data portions of the transaction) completed. In most situations, it is undesirable to deny a processor access to a bus pending completion of an entire transaction by another processor.
One solution to this problem has been to separate the address and data bus portions of the system bus, and to provide separate arbitration for gaining access to each of the buses. For example, rather than requesting access (or master) of the system bus, a first processor may request access to the address bus. If the address bus is available, the first processor can present address information on the address lines, even though a second processor is bus master of the data bus. Access to the data bus by the first processor operates in a similar fashion.
Thus, by separating arbitration for accessing the address bus from that of the data bus, multiple masters are allowed to utilize portions of the system bus simultaneously. An example of an environment that provides for such split address and data buses is the system bus for the PowerPC 603, manufactured by Motorola.
When the address and data portions of a bus are separate, and are shared by multiple bus masters, a system is required to allow master devices to request, and gain access to the address and data buses, independently. This is typically provided via an arbiter, and an arbitration protocol.
The arbiter is coupled to each device on the bus that can act as a master device. A master that wishes to access either the address or data portions of the system bus presents a bus request (address bus request, or data bus request) to the arbiter. The arbiter, upon receipt of a request, utilizes its predefined protocol to determine when to grant the master access to either of the address or data bus. When it determines that the requesting master can access the address bus or the data bus, it provides that master with a bus grant signal (pertaining to the requested bus). Upon receipt of the grant signal, the requesting master begins driving the bus (address or data).
In some instances, master devices drive the data bus for a period of time that is unknown to the arbiter. That is, when the arbiter grants a master device access to the data bus, the arbiter does not know how long the master device will drive the bus. The master device may require only a single cycle to perform its data transfer. Alternatively, the master device may be performing an extensive transfer operation, and may require the data bus for a number of cycles, (e.g., 16 cycles). Since the arbiter does not know how long a master device will drive the data bus, it is unable to grant access to another requesting master until it knows that the data bus is released.
In multiple master environments, where master devices drive the data bus for an indeterminate period of time, a xe2x80x9cdata releasexe2x80x9d signal was developed to indicate when the current bus master has released the data bus. That is, the a data release signal is driven by the current master when it relinquishes control of the data bus. When the arbiter sees the data release signal, it grants access to the next requesting bus master.
A problem that exists with the present data release methodology is that arbiters typically do not grant mastership of the data bus to a requesting bus master until after the data release signal is driven (by the current master device). When this is the case, there is usually a delay between the time the current master device releases the data bus, and the time the next bus master device is granted mastership, and begins driving data. This delay, or latency, associated with turning mastership of the data bus over from one master to another, is often several cycles long. One skilled in the art will appreciate that any delay in granting a requesting master access to the data bus is undesirable.
Therefore, what is needed is a data release methodology that reduces the latency typically associated with turning mastership of the data bus over between multiple master devices.
Furthermore, what is needed is an on-chip system bus that incorporates a data release methodology to optimize data bus bandwidth within a multi-master environment.
The present invention provides an innovative on-chip system bus having a bus arbiter, and a plurality of data master devices that perform data transfers. Each of the master devices includes a bus interface and data release drive and control. The bus interface allows its associated master device to communicate on the system bus. The data release drive and control, is coupled to the bus interface, to receive a data bus grant signal from the bus arbiter, and to generate a data release signal to the system bus during the last cycle of the data transfers. In addition, the data release drive and control monitors the data release signal from other devices and latches it to determine whether its master device can begin driving data onto the data bus. By separating the bus grant signal from the bus release signal, by allowing the bus grant signal to be provided to the next bus master, and by overlapping generation of the bus release signal with the last cycle of the data transfer, latency between the current bus master and the next bus master is reduced.
In another aspect, the present invention allows a master that has asserted release on the last cycle of a previous transaction to begin re-using the data bus if it still has a grant signal. In this case all other masters that latched the release signal resets it when they see a re-use of the data bus.
In another aspect, the present invention provides a processing device configured to access an on-chip bus to perform a data transfer. The access is initiated when the processing device generates a data bus request signal to a bus arbiter. The processing device includes a bus interface, for coupling the processing device to the on-chip bus, and data release drive and control logic. The drive and control logic is coupled to the bus interface, and presents a data release signal to the on-chip bus during the last cycle of the data transfer. In addition, the bus arbiter generates a data bus grant signal to the processing device, if a data portion of the on-chip bus is available. Also, the bus arbiter generates a data bus grant signal to the processing device, if a data portion of the on-chip bus is not available, but will become available when released by a current data bus master.
In yet another aspect, the present invention provides computer program product for use with a computing device. The computer program product includes a computer usable medium having computer readable program code embodied in said medium for causing an on-chip computing bus to be developed. The computer readable program code includes first computer readable program code to provide a bus interface, for coupling a processing device to the on-chip computing bus, and second computer readable program code to provide data release drive and control logic that is coupled to the bus interface, that presents a data release signal to the on-chip computing bus during the last cycle of a data transfer.
An additional feature of the present invention provides a method for granting access to a data bus within an on-chip multi-master environment. The method includes: when the data bus is being accessed by a first master device, providing a data bus grant signal to a second master device; before the first master device relinquishes access to the data bus, driving a data bus release signal to the second master device; and accessing the data bus by the second master device, after it receives the data bus release signal.
Other features and advantages of the present invention will become apparent upon study of the remaining portions of the specification and drawings.